ソフトウェアアーキテクチャの基礎輪読会 20章

日付：2023/11/30

章：20章 アーキテクチャ上のリスクを分析する

アーキテクチャのリスクを特定していくための主要なテクニックとプラクティスについて

図20−1参照

リスクを「影響度」と「発生する可能性」の2つの側面で、低(1), 中(2), 高(3)に分類する。

各グリッドの数値をかけ合わせることで、リスクを表す数値が得られる。

1~2が低リスク(緑)、3~4が中リスク(黃)、6~9が高リスク(赤)

メリット

主観の度合いを減らし、客観的な数値が得られる。

Tips

リスクマトリックスを活用してリスクを限定する際には、まず影響度を考慮し、次に可能性を考慮しよう。

リスクアセスメント

図20-2参照

リスク基準 = スケーラビリティ、可用性、パフォーマンスなど....

相対的なスコアで見ることで、特定のリスク基準またはドメイン領域でのリスクの改善や低下を追える。

問題点

この評価レポートは状態が改善しているのか悪化しているのかを示していない(スナップショットでしかない)。

改善

図20−5参照

直感的にわかりやすい物が良い

各リスク基準を客観的に分析することで、傾向を観察し、各リスク基準が改善しているのか悪化しているのかわかる。

リスクストーミング

アーキテクト、シニア開発者、テックリードなど複数人で、アーキテクチャの特定のリスクを判断するための共同作業

メリット

参加した開発者のアーキテクチャに対する理解が深まる。

アーキテクチャのリスクに対して実装面での視点も得られる。

リスク領域を見落とす可能性が減る。

リスクストーミングのやり方

アーキテクチャ内のリスク領域を各参加者が個々に特定する。

個々でリスクマトリックスをする。

アーキテクチャのどの部分にリスクがあると考えているかを個人で明らかにする

ほとんどのリスクストーミングでは、1回に1つの側面（パフォーマンスなど）のみを分析する

図 20-7参照

アーキテクチャ内のリスクに関して、参加者全員で話し合って認識をあわせる(高か中か低か)

リスクごとに色の付いた付箋をアーキテクチャ図に貼っていく

未知の技術には常に高リスクの評価(9)を割り当てる

リスクの軽減のため、アーキテクチャの特定の領域を変更または強化する必要がある。

追加コストが生じるため、ステークホルダーと相談。

例)

中央DBがシステム全体の可用性に関して中程度のリスクがある

-> DBをクラスタリングし、別々の物理DBに分割(20000ドルの追加コスト)

-> クラスター化をやめてDBを2つに分割(8000ドルに削減)

ユーザーストーリーリスク分析

リスクストーミングはソフトウェア開発の側面にも利用できる。

背景 : 決められた期間中に特定の機能を実装したい

「機能を実装できなかったときの全体的な影響」と「期間内に実装できない可能性」の2側面でリスクマトリックス

チームはリスクの高い機能を特定し、優先順位がつけられる。

影響が大きく、期間内に実装できない可能性が高いものを優先

リスクストーミング例

患者にアドバイスをする看護師をサポートするコールセンターシステムの例

リスクストーミングの参加者3人

中央DBと診断エンジンが高リスク

中央DBが停止するとコールセンターの機能が止まる。 -> DBを分割

診断エンジンが止まると、結構なんにもできない。

診断エンジンは外部システムなため可用性のコントロールができない。こういうときは、サービスレベル契約(SLA)やサービスレベル目標(SLO)が公表されているかを調査するという方法がある。

弾力性

参加者全員が診断エンジンインターフェイスを高リスクと認識。1秒に500回のリクエストしかないことから、アウトブレイクやインフルエンザの時期を懸念。

非同期のメッセージングキューを用意する。

アウトブレイク時用のキャッシュを用意する。

セキュリティ

参加者全員がAPIゲートウェイを高いセキュリティリスク(6)と認識

患者のカルテは機密情報なため、重要

ユーザー種類ごとに別々にAPIゲートウェイを持つことで、セキュリティ面の懸念を改善

リスクストーミングは継続的にやるべき

リスクストーミングの頻度は、変更の頻度、アーキテクチャのリファクタリング作業、アーキテクチャのインクリメンタルな開発など、多くの要因に左右される。

主要な機能が追加された後や、すべてのイテレーションの終わりに、いくつかの側面に対してリスクストーミングをするのが一般的。

応用

code:sample.kt

質疑応答